home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 3
/
Cream of the Crop 3.iso
/
utility
/
fsco3712.zip
/
SPECS.DOC
< prev
Wrap
Text File
|
1993-12-13
|
4KB
|
74 lines
*FSCODE FILE FORMAT SPECIFICATIONS*
By Flavio Stanchina
FScoded files begin with the line
!start <file name>
The <file name> is everything that follows the space after `!start' until the
end of line, spaces included; it is recommended to replace spaces with
underlines on machines incapable of using spaces in file names.
Then follows the encoded data; each group of 5 characters represents a
longword of the original data converted in base 85, using the ASCII
characters from 42 (;-) to 126 (from `*' to `~') as digits, most significant
digit first, and padded with "zeros" (remember that our "zero" is really
`*'). Encoded data can be arbitrarily interspersed with blanks (spaces, line
feeds, etc), that are to be skipped when reading in the data for decoding.
You might have noticed that not all files are longword-aligned in their
lenght: for this reason, the last group of five characters can contain the
character `#' (ASCII 35) in it's one to three most significant digits, which
means that one to three of the most significant bytes in the last longword
are to be considered empty and are not to be written to the output file when
decoding. For example, a file of length 2 would look like this:
!start 42
##+r;
!end 2 A8D1BE1F
This means that you must decode this longword of data as if it was only 3
characters long (this is equivalent to taking the #'s as *'s, i.e zeros) and
write out only the two least significant bytes. Probably you can manage to
understand all of this by looking at what happens in the Decode() function
when a `#' is found.
Please note that the current implementation does neither check that the file
correctly terminates after a partially filled longword, nor allow a partially
filled longword to appear in the middle of the file (which would be somewhat
easier to do, but would slow down a bit the decoding). If it finds a `#' in
the middle of the file, it will simply mess up the decoding process from
there on. However, the encoding routine does it right, so why should the
decoding fail? :-)
Decoding stops when the ending line is found. It has the form
!end <size> <CRC>
with <size> in decimal and <CRC> in hexadecimal representation. <size> is
the size in bytes of the original file. <CRC> is a 32-bit CRC calculated
using the polynomial 0x04C11DB7 (AUTODIN II, Ethernet, & FDDI); the algorithm
has been taken from the comp.compression FAQ list of october 1992, but has
been changed to NOT complement the resulting CRC for simpler implementation.
See the source code for the exact algorithm.
Control lines (`!start' and `!end') must start on the first column; the `!'
character has been chosen as the introducer of the control lines because it
is not used in the encoded data, thus provides a reliable way to distinguish
the two kinds of input.
// The `start' and `end' keywords can be lowercase, uppercase, or a mixture
// of the two, but it is recommended to write them out as lowercase for
// consistency.
Some notes on the encoding method. 85^5 is slightly greater than 2^32; this
is the best compromise between simplicity and speed on one side, and
efficiency on the other, if we want to encode all possible 256 byte values to
the limited set of 95 ASCII characters allowed over the various nets.
Encoding more bits at a time would require quite complex algotythms, because
most computers and most programming languages (C, in particular) do not have
arithmetic instructions that can handle numbers wider than 32 bits; on the
other side, to increase efficiency over this method you should encode as much
as 32 bytes at a time into 39 characters, gaining only one character over 40.
Definitely too much trouble.